摘要
這篇文章主要介紹了 Agentic Design Pattern 中的 Planning 模式，它賦予 AI 自主規劃的能力，讓 AI 能夠處理那些難以預先定義固定步驟的複雜任務。文章分為兩個主要部分：第一部分介紹了 Planning 模式的運作原理，以及如何使用技術實現它。第二部分介紹了 Plan-and-Solve 論文，它提出了一種新的提示方法，讓大型語言模型能夠明確地為解決給定問題制定計劃，並生成中間推理過程。文章詳細說明了 Plan-and-Solve 提示的步驟和效果，以及如何使用 LangChain 和 LangGraph 來實現它。
總體而言，這篇文章探討了 Planning 模式在賦予 AI 自主規劃能力方面的作用，以及 Plan-and-Solve 論文在促進這種能力發展方面的貢獻。它旨在為讀者提供對 Planning 模式的深入理解，並展示其在實際應用中的潛力。
Planning 模式的核心在於賦予 AI 自主規劃能力。想像一下，當我們要求 AI 代理進行某個主題的在線研究時，它能夠自動將這個大任務分解為多個小步驟：研究特定子主題、綜合發現、最後編寫報告。這種能力使 AI 能夠處理那些難以預先定義固定步驟的複雜任務。
關鍵亮點：Planning 使 AI 能夠處理那些難以預先定義固定步驟的複雜任務。
首先，AI會理解並分析給定的任務。就像我們讀題一樣，AI需要先搞清楚「題目」在問什麼。接著，它會從自己的「知識庫」——也就是訓練數據中檢索相關的信息。這就像我們回憶過去學過的知識一樣。
理解任務後，AI會將大任務分解為多個小的、可管理的子任務。這個過程很像我們解決數學題時的思路：先把複雜的問題拆解成幾個小問題。
對每個子任務，AI都會生成具體的執行步驟。同時，AI還會考慮每個步驟所需的資源，就像我們在做實驗前會準備好所有需要的器材一樣。
在執行過程中，AI還會不斷監控和調整。如果某個步驟出了問題，它會及時改變策略。這種靈活性是Planning的一大優勢。
最後，AI會將所有子任務的結果整合起來，生成最終的輸出。這就像我們完成一篇論文，最後要把所有章節組合成一個完整的作品。
Planning 模式的實現通常涉及以下步驟：
這邊採用 HuggingGPT 例子介紹
為了精簡說明，內容大幅度簡化 HuggingGPT 運作細節，對這一 part 感興趣的朋友，可以前往 HuggingGPT 論文查看，圖片與過程取自原文 Response 中。(https://arxiv.org/abs/2303.17580)
假設請 Agent 將一張男孩的照片轉換為相同姿勢的女孩圖片，可能會被分解為：
LLM 可能會輸出類似這樣的結構化字符串來指定計劃：
{tool: pose-detection, input: image.jpg, output: temp1}
{tool: pose-to-image, input: temp1, output: final.jpg}
此結構化輸出指定了要執行的兩個步驟，然後觸發軟體呼叫姿勢偵測工具，然後呼叫姿勢到影像工具來完成任務。 （此範例僅用於說明目的；HuggingGPT 使用不同的格式。）
Planning 模式的主要優勢在於其靈活性和自主性，能夠處理複雜且難以預先定義的任務。然而，這種自主性也帶來了一定的不可預測性。相比於其他較為成熟的模式（如 Reflection 和 Tool Use），Planning 技術仍在發展階段，其行為有時難以準確預料。
想像你有一個AI助手，它能回答問題，但總是一步一步地摸索。有時候它會迷失方向，或者忘記之前的步驟。這就是傳統的"Action Agents"（如ReAct框架）的工作方式。Plan-and-Solve就像給AI裝上了一個超級大腦。它不再是盲目地一步步摸索，而是先制定一個全面的計劃，然後有條不紊地執行。
傳統的「Action Agents」框架，即所謂的ReAct模式，正逐漸讓位於更為先進的系統。這種演進是因應日益複雜的用戶需求而生，也反映了開發者對AI代理的依賴程度不斷提升。
ReAct框架的運作機制可以簡化為一個循環過程：首先，接收用戶輸入；其次，AI代理根據情境選擇合適的工具及其參數；接著，調用選定的工具並記錄結果；然後，將這些資訊回饋給代理以決定下一步行動。這個過程會不斷重複，直到AI認為無需再使用工具，便直接回應用戶。
然而，隨著技術的進步，這種方法的局限性逐漸顯現。為了應對更為複雜的任務，「Plan-and-Execute Agent」應運而生。這種新型代理將規劃與執行階段分離，實現了更為精準和可靠的操作模式。
論文提出了PS提示（Plan-and-Solve prompting），這是一種新的零樣本思維鏈（zero-shot Chain-of-Thought, CoT）提示方法。它使大型語言模型（Large Language Models, LLMs）能夠明確地為解決給定問題制定計劃，並在預測輸入問題的最終答案之前生成中間推理過程。與先前的少樣本CoT方法不同，後者在提示中包含了逐步的少量示範(Few-shot)例子，而零樣本PS提示方法不需要示範例子，其提示僅涵蓋問題本身和一個簡單的觸發句。類似於零樣本CoT，零樣本PS提示包含兩個步驟。在第一步中，提示首先使用提議的提示模板進行推理，以生成問題的推理過程和答案。在第二步中，它使用答案提取提示來提取答案以進行評估，例如「因此，答案（阿拉伯數字）是」。
原文描述不懂的話，讓我們接著往下看內容
PS提示由兩個部分組成：首先制定計劃，將整個任務分割為較小的子任務，然後根據計劃執行子任務。
可以看到 (a) 為 zero-shot CoT 執行結果。零樣本 CoT 鼓勵LLMs用「Let’s think step by step」[1]來產生多步驟推理，當問題複雜時，仍然可能產生錯誤的推理步驟。
與零樣本 CoT 不同，(b) Ps Prompting 首先詢問LLMs透過制定逐步計劃並執行該計劃來找到答案，從而製定解決問題的計劃。使用 Prompt 為「Let's first understand the problem and devise a plan to solve the problem. Then, let's carry out the plan to solve the problem step by step.」[2][1]論文 Prompt ID 編號 101; [2]論文 Prompt ID 編號 102。查看原始專案Github連結：https://github.com/AGI-Edgerunners/Plan-and-Solve-Prompting
為了進一步提高生成推理步驟的質量，PS提示中添加了更詳細的說明。
具體來說，增加了「提取相關變數及其對應數字」和「計算中間結果（注意計算和常識）」的指令。這種新的提示變體被稱為“PS+提示”策略。
這項研究探討了不同方法在常識推理數據集上的表現，主要聚焦於 CommonsenseQA 和 StrategyQA 兩個數據集。研究結果如下：
研究方法：
主要發現：
研究意義：
局限性：
總體而言，這項研究展示了 PS+ 提示策略在常識推理任務中的潛力，特別是在零樣本學習情境下。然而，要達到手動設計的少樣本方法的效果，仍有進一步提升的空間。
CommonsenseQA(ACL’19;https://arxiv.org/abs/1811.00937)主要針對常識推理的多選題資料集。StrategyQA(TACL’21;https://arxiv.org/abs/2101.02235)一個需要隱含推理步驟來回答是非問題的資料集
Planning 模式作為 Agentic Design Pattern 的組成部分，正在重塑 AI 處理複雜任務的方式。本文將深入探討 Planning 模式的實際應用，特別聚焦於 LangChain 這個強大的框架，展示如何將理論付諸實踐。
在閱讀玩經典論文 Plan-and-Solve 文章後，可得到一個簡單的架構來表達 Planning Agent，主要由兩個組件合作：
一旦執行完成，代理會再次被調用，並發出重新規劃提示，讓它決定是否完成回應或是否產生後續計劃（如果第一個計劃沒有達到預期效果）。
這種代理設計讓我們不必呼叫大型規劃器LLM對於每個工具調用。它仍然受到串行工具呼叫的限制並使用LLM對於每個任務，因為它不支援變數分配。
注意：當前實現可能需要較多 API 調用，但這是為了長遠效益的權衡。
以下內容採用 LangChain 實作，記得文章中最重要的兩塊嗎？Planner, Executors ，這邊在 Langchain 採用 agent_tool 來達成，如何拆解任務、決斷要不要往下執行主要仰賴語言模型能力決定，工具則交給 Executors 。為此我們來往下看。
在計劃與執行代理系統中，工具扮演著至關重要的角色。它們就像是代理的"手"和"眼睛"，使其能夠與外界互動並執行各種任務。
search = DuckDuckGoSearchAPIWrapper()
llm = OpenAI(temperature=0)
llm_math_chain = LLMMathChain.from_llm(llm=llm, verbose=True)
tools = [
Tool(
name="Search",
func=search.run,
description="useful for when you need to answer questions about current events",
),
Tool(
name="Calculator",
func=llm_math_chain.run,
description="useful for when you need to answer questions about math",
),
]
設置 Agent 可以使用的工具，包括搜索引擎和計算機：搜索工具使用 DuckDuckGo 搜索 API，允許代理查找最新的信息和事實。計算工具利用 LLMMathChain，這是一個結合了語言模型和數學運算能力的工具。
提示：根據任務的具體需求，您可以添加更多專門的工具，如自然語言處理、圖像識別、或特定領域的API等。工具的多樣性直接影響代理的能力範圍。
完成工具配置後，下一步是設置計劃者（Planner）、執行者（Executor）和最終的代理（Agent）。這三個組件共同構成了計劃與執行代理系統的核心架構
model = ChatOpenAI(temperature=0)
planner = load_chat_planner(model)
executor = load_agent_executor(model, tools, verbose=True)
agent = PlanAndExecute(planner=planner, executor=executor)
計劃者負責制定解決問題的整體策略。它使用 ChatOpenAI 模型，這是一個強大的語言模型，能夠理解複雜的指令並生成詳細的計劃。計劃者的主要任務是將大型任務分解為可管理的子任務。
執行者負責實施計劃者制定的策略。它被賦予了使用各種工具的能力，可以執行搜索、計算等具體操作。執行者的 verbose=True 設置允許我們看到執行過程中的詳細信息，這對於調試和理解代理的決策過程非常有用。
代理是計劃者和執行者的組合體，代表了整個系統的智能核心。它協調計劃的制定和執行，確保整個過程的順利進行。
提示：調整模型的 temperature 參數可以影響代理的創造性和確定性。較低的值（如本例中的 0）會使輸出更加一致和確定，而較高的值會增加創造性但可能降低準確性。
讓我們來看看代理如何處理一個關於飲料價格的多步驟查詢：
agent.run(
"高雄的五十嵐飲料店一杯珍奶多少錢？如果要五杯總共多少？最後回應記得用繁體中文"
)
這個任務要求代理完成兩個子任務：
Agent 綜合了搜索結果和計算,給出了以下回答:
『單杯珍珠奶茶的價格在五十嵐飲料店約為 TWD40 - 60（約 USD1.3 - 1.95）每杯。五杯珍珠奶茶的總價格為 TWD200（約 USD6.5）。』
本文將介紹如何創建一個"Plan-and-Solve"風格的智能代理。這種方法受到 Plan-and-Solve 論文和 Baby-AGI 項目的啟發。其核心理念是先制定多步驟計劃，然後逐項執行。完成每個任務後，代理可以重新評估計劃並進行必要的調整。
[圖片：Plan-and-Solve流程圖]
與傳統的 ReAct 風格代理相比，"Plan-and-Solve"方法具有以下優勢：
接下來，我們將使用 LangGraph 來實現這一智能代理。最終，代理將生成類似於 這個示例 的執行軌跡。
這個工作流程圖定義了代理的整體行為：從規劃開始，然後執行任務，之後重新評估並決定是繼續執行還是結束。
為了有效地管理代理的執行過程，我們需要定義一個清晰的狀態結構。這個結構將包含以下關鍵信息：
class PlanExecute(TypedDict):
input: str # 原始輸入
plan: List[str] # 當前計劃
past_steps: Annotated[List[Tuple], operator.add] # 已執行的步驟
response: str # 最終響應
先來建置 Planner，規劃是整個過程的核心。它負責生成初始計劃。我們將使用 OpenAI 的語言模型來生成這個計劃。
class Plan(BaseModel):
"""Plan to follow in future"""
steps: List[str] = Field(
description="different steps to follow, should be in sorted order"
)
再來建置 Executor，根據當前的執行狀態來決定是繼續執行還是提供最終回應。
class Act(BaseModel):
"""Action to perform."""
action: Union[Response, Plan] = Field(
description="Action to perform. If you want to respond to user, use Response. "
"If you need to further use tools to get the answer, use Plan."
)
添加判斷是否持續執行還是回應的條件邊
def should_end(state: PlanExecute) -> Literal["agent", "__end__"]:
if "response" in state and state["response"]:
return "__end__"
else:
return "agent"
提示：實作上沒有一對一跟框架相同，實務上還是有些限制要處理，更全面了解的話，請務必跑過一次程式碼。程式碼
最後，讓我們運行一個範例來測試我們的"Plan-and-Execute" Agent：
溫腥提示：我無法確定當前的你需要執行幾次才可以達到想要的答案，該方法很大一塊邏輯是在 Planner 身上。
本文深入探討了 Agentic Design Pattern 中的 Planning 模式，特別聚焦於 Plan-and-Solve 方法的理論基礎和實際應用。我們可以得出以下幾點結論：
Planning 模式為 AI 代理提供了自主規劃的能力，使其能夠處理複雜且難以預定義的任務。
Plan-and-Solve 方法通過將任務分解為可管理的子任務，並在執行過程中進行動態調整，大大提高了 AI 系統的效能和靈活性。
LangChain 和 LangGraph 等框架為實現 Planning 模式提供了強大的工具，使得開發者能夠更容易地構建具有規劃能力的 AI 系統。
實驗結果表明，採用 Planning 模式的系統在處理複雜任務時，相比傳統方法具有明顯優勢。
總的來說，Planning 模式代表了 AI 系統向更高層次智能邁進的重要一步。隨著技術的不斷進步，我們有理由相信，具有自主規劃能力的 AI 系統將在未來發揮越來越重要的作用，為人類解決更加複雜和多樣化的問題。
即刻前往教學程式碼 Repo，親自動手體驗 AI 代理規劃的力量吧！別忘了給專案按個星星並持續關注更新，讓我們一起探索AI代理的新境界。
iThome鐵人賽
看影片追技術